Review: fix(middleware): align matcher validation

Reviewed all 30 files. This is a solid, security-focused refactor that replaces two hand-rolled ReDoS heuristics with a deterministic structural analyzer plus a faithful port of path-to-regexp 6.3, and validates matchers at config time. Test coverage is excellent — the new shims.test.ts case compiles every fixture pattern with next/dist/compiled/path-to-regexp and asserts vinext produces the identical RegExp.source/flags, and the auth fixture exercises dev, Node prod, and Workers. I ran tests/shims.test.ts (1214 pass) and tests/middleware-matcher-auth.test.ts (27 pass), plus vp check on the changed source files (clean).

Verified the key parity claims against Next.js canary (.nextjs-ref):

• _matchConditionValue / query has semantics match matchHas in prepare-destination.ts: empty/omitted value is a presence check requiring a non-empty actual value, duplicate query keys select the last element (value.slice(-1)[0]), and a duplicate key is truthy even when its final value is empty.
• middleware-path-to-regexp.ts token output and compiled regex match the vendored path-to-regexp, including the normalizeMiddlewarePathTokens slash-prefix retry.

No blocking issues found. A few observations:

Observations (non-blocking)

1. Two ReDoS analyzers now coexist. unsafeTokenReason runs both the AST-based analyzeRegexSafety (which already reports "overlapping sequential repetition") and the separate hand-rolled string scanner hasOverlappingSequentialRepetition in middleware-matcher-pattern.ts:117. Both leaning toward false-positives (fail-closed) is fine as belt-and-suspenders, but it's a maintenance burden — two code paths that must stay in agreement. Worth a follow-up to consolidate on the AST analyzer if it can cover the string-scanner cases, or a comment explaining why both are retained.

2. Config headers/redirects/rewrites still use the old tokenizer. matchConfigPattern in config-matchers.ts:724+ retains the legacy hand-rolled tokenizer + extractConstraint, so only middleware matchers gained the path-to-regexp-parity implementation. This is consistent with the PR's scope ("middleware matcher validation"), and those config paths do benefit from the stricter shared analyzeRegexSafety via safeRegExp. Flagging only so it's a conscious decision — config-route matching still diverges from Next.js's path-to-regexp semantics.

3. isSafeRegex is now strictly stricter for all callers. Since safeRegExp powers config header/redirect/rewrite compilation too, patterns that previously passed the naive nested-quantifier heuristic may now be rejected (returning null). All call sites I checked handle null gracefully (fall back to linear scan / non-match / warn), and the rejected patterns are genuinely backtracking-prone, so the direction is safe. Callers relying on previously-accepted pathological patterns would see a behavior change, but that's the intended hardening.

4. matchesMiddleware fail-open shift is correct. Non-array matcher configs and invalid matcher objects now return true (middleware runs for all paths) instead of false. This is the security-correct direction (don't silently bypass an auth guard) and Next.js validates these at build time anyway, so runtime only sees them as defense-in-depth.

Performance note

The benchmark comment reports ~+1.8–3.0% growth across server/client/RSC bundle sizes, attributable to the new 899-line regex-safety.ts + 312-line pattern module + 281-line path-to-regexp. Given AGENTS.md's guidance to keep the common request path lightweight, consider whether regex-safety.ts (only needed at matcher-compile time, which is cached per pattern) can be lazily imported off the hot request path rather than statically pulled into the shared RSC/SSR/worker closures. Not blocking, but the size regression is measurable.

Overall: correct, well-tested, and faithful to Next.js. Approving direction; the items above are follow-ups rather than fixes required for merge.